-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Batched driver move abstraction #3762
Batched driver move abstraction #3762
Conversation
Need to follow up and add comments to everything |
I added documentation detailing the intention of each method in the MoveAbstraction class and describing each member variable. Also updated the docs to include the spin mass in the batched driver sections |
Here is my thoughts
Replace mw_makeMoveWithSpin with mw_makeSpinMove which only deal with spin part. Call flex_makeMove and mw_makeSpinMove in the abstraction. still thinking about a better name for MoveAbstraction. MoveManipulator? The object name should be a noun, not "move". Will can do the change once we settle the class name. |
src/QMCDrivers/MoveAbstraction.h
Outdated
#ifndef QMCPLUSPLUS_MOVEABSTRACTION_H | ||
#define QMCPLUSPLUS_MOVEABSTRACTION_H | ||
|
||
#include "QMCDriverNew.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move the ENUM in this class. This class doesn't need to depend on QMCDriverNew
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR sets up a new state machine and mixed data and operations class.
Due to the large upfront capture of variables and state members it hides the actual data dependence of many steps of the qmc section which I consider to be undesirable.
The methods are almost all state transformations of the object and not clean functions.
While I feel that breaking up advance walkers into pure functions would be worth while I think templating or giving them if constexpr sections based the Monte Carlo Coordinate type is a much cleaner way to add this functionality.
I would propose working from a different start such as in #3767
@PDoakORNL can we first complete this one and then work on refactoring? #3767 is a prototype and only partially address what is abstracted in this PR. So it takes a bit more time to work out a fully satisfactory design. |
This is taken care of with the recent push. Looking at the changes to particleset now. |
src/QMCDrivers/VMC/VMCBatched.cpp
Outdated
@@ -233,7 +213,13 @@ void VMCBatched::runVMCStep(int crowd_id, | |||
const bool recompute_this_step = (sft.is_recomputing_block && (step + 1) == max_steps); | |||
// For VMC we don't call this method for warmup steps. | |||
const bool accumulate_this_step = true; | |||
advanceWalkers(sft, crowd, timers, *context_for_steps[crowd_id], recompute_this_step, accumulate_this_step); | |||
const bool spin_move = crowd.get_walker_elecs()[0].get().isSpinor(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line can be dangerous if there is no element.
Pass the state via the sft object.
Also use population_.get_golden_electrons()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
src/QMCDrivers/VMC/VMCBatched.cpp
Outdated
@@ -80,68 +78,37 @@ void VMCBatched::advanceWalkers(const StateForThread& sft, | |||
std::vector<std::reference_wrapper<TrialWaveFunction>> twf_accept_list, twf_reject_list; | |||
isAccepted.reserve(num_walkers); | |||
|
|||
MoveAbstraction<COORDS> move(ps_dispatcher, walker_elecs, step_context.get_random_gen(), sft.drift_modifier, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let us change this to 'mover' a noun.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I'm inclined to merge this for fast turnaround and avoid working on forks although I consider MoveAbstraction should go away as we get #3767 ready.
Made a significant change to this PR. This should be more in line with what @PDoakORNL was thinking. I completely removed the MoveAbstraction class which this PR introduced. With a little more work, the advanceWalkers will be further simplified so it doesn't have to have any "if constexpr (CT==CoordsType::POS_SPIN)" code |
Will start rereview this afternoon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a good step. If there is time fix the attribution for TauParams.
@@ -386,6 +385,16 @@ class ParticleSet : public QMCTraits, public OhmmsElementBase, public PtclOnLatt | |||
const std::vector<bool>& isAccepted, | |||
bool forward_mode = true); | |||
|
|||
/** batched version of acceptMove and reject Move fused, but only for spins | |||
* | |||
* note: should be called BEFORE mw_accept_rejectMove since the active_ptcl_ gets reset to -1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for documenting the state requirement.
src/QMCDrivers/TauParams.hpp
Outdated
// | ||
// Copyright (c) 2022 QMCPACK developers. | ||
// | ||
// File developed by: Ye Luo, [email protected], Argonne National Laboratory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ye-luo didn't write this.
Put my name, yours and we have been writing
// Refactored from MCCoords.hpp
instead of File created by.
I think that is more meaningful when you're tearing up or porting a well known file.
The name is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did the rewriting. So I will take care of this.
move switch from TWFdispatcher into TrialWaveFunction
elec_.mw_makeMove(p_list, iat, displs); | ||
elec_.mw_makeSpinMove(p_list, iat, sdispls); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could update this test to call the new APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, I was just working on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
ok, added a unit test for the TWFGrads class I added. With the current changes, there are only a few spots left in VMCBatched and DMCBatched that need to be abstracted, but those will be handled by a subsequent PR. This one is large enough as it is |
Test this please |
Test this please |
Please review the developer documentation
on the wiki of this project that contains help and requirements.
Proposed changes
This PR adds an abstraction layer to the batched drivers for the particle moves. It is intended to keep the VMC/DMC advanceWalkers agnostic about the actual moves that are being done (just particle positions, positions and spins, etc). Right now advanceWalkers is templated on a move type, and uses the templated class MoveAbstraction to handle the specifics of the moves. I am happy to change any names for classes/functions/etc here to make things more clear, I was more concerned with getting something working.
note: Eventually this should be able to handle the work needed for the L2potentials as well
part of #3712, and would allow me to delete #3742
What type(s) of changes does this code introduce?
Delete the items that do not apply
Does this introduce a breaking change?
What systems has this change been tested on?
macOSX
Checklist
Update the following with a yes where the items apply. If you're unsure about any of them, don't hesitate to ask. This is
simply a reminder of what we are going to look for before merging your code.